Reactin salaisuus: Syväsukellus sovitusalgoritmiin ja virtuaalisen DOMin vertailuun

` voitaisiin esittää näin:

{ type: 'div', props: { className: 'container', children: 'Hei maailma' } }

Koska nämä ovat vain JavaScript-olioita, niiden luominen ja käsittely on uskomattoman nopeaa. Se ei vaadi mitään vuorovaikutusta selainten API-rajapintojen kanssa, joten uudelleenlaskentoja tai -piirtoja ei tapahdu.

Miten virtuaalinen DOM toimii?

VDOM mahdollistaa deklaratiivisen lähestymistavan käyttöliittymäkehitykseen. Sen sijaan, että kertoisit selaimelle miten DOMia muutetaan askel askeleelta (imperatiivinen), ilmoitat vain miltä käyttöliittymän tulisi näyttää tietyssä tilassa (deklaratiivinen). React hoitaa loput.

Prosessi näyttää tältä:

1. Alkuperäinen renderöinti: Kun sovelluksesi latautuu ensimmäistä kertaa, React luo täydellisen virtuaalisen DOM-puun käyttöliittymällesi ja käyttää sitä luodakseen alkuperäisen todellisen DOMin.
2. Tilan päivitys: Kun sovelluksen tila muuttuu (esim. käyttäjä napsauttaa painiketta), React luo uuden virtuaalisen DOM-puun, joka heijastaa uutta tilaa.
3. Vertailu (Diffing): Reactilla on nyt muistissa kaksi virtuaalista DOM-puuta: vanha (ennen tilan muutosta) ja uusi. Se ajaa sitten "diffing"-algoritminsa vertaillakseen näitä kahta puuta ja tunnistaakseen tarkat erot.
4. Ryhmittely ja päivitys: React laskee tehokkaimman ja minimaalisen joukon operaatioita, jotka tarvitaan todellisen DOMin päivittämiseksi vastaamaan uutta virtuaalista DOMia. Nämä operaatiot ryhmitellään yhteen ja sovelletaan todelliseen DOMiin yhtenä optimoituna sekvenssinä.

Ryhmittelemällä päivityksiä React minimoi suoran vuorovaikutuksen hitaan DOMin kanssa, mikä parantaa suorituskykyä merkittävästi. Tämän tehokkuuden ydin piilee "diffing"-vaiheessa, joka tunnetaan virallisesti sovitusalgoritmina.

Reactin ydin: Sovitusalgoritmi

Sovitus (Reconciliation) on prosessi, jonka kautta React päivittää DOMin vastaamaan uusinta komponenttipuuta. Algoritmia, joka suorittaa tämän vertailun, kutsumme "vertailualgoritmiksi" (diffing algorithm).

Teoreettisesti minimaalisen muunnosmäärän löytäminen yhden puun muuntamiseksi toiseksi on hyvin monimutkainen ongelma, jonka algoritmin kompleksisuus on luokkaa O(n³), missä n on solmujen määrä puussa. Tämä olisi liian hidasta todellisiin sovelluksiin. Ratkaistakseen tämän Reactin tiimi teki nerokkaita havaintoja siitä, miten verkkosovellukset tyypillisesti käyttäytyvät, ja toteutti heuristisen algoritmin, joka on paljon nopeampi – toimien O(n)-ajassa.

Heuristiikat: Miten vertailusta tehdään nopeaa ja ennustettavaa

Reactin vertailualgoritmi perustuu kahteen pääoletukseen eli heuristiikkaan:

Heuristiikka 1: Eri elementtityypit tuottavat erilaiset puurakenteet

Tämä on ensimmäinen ja suoraviivaisin sääntö. Verratessaan kahta VDOM-solmua React tarkastelee ensin niiden tyyppiä. Jos juurielementtien tyyppi on erilainen, React olettaa, ettei kehittäjä halua yrittää muuntaa toista toiseksi. Sen sijaan se omaksuu jyrkemmän, mutta ennustettavan lähestymistavan:

• Se purkaa koko vanhan puun, poistaen (unmounting) kaikki vanhat komponentit ja tuhoten niiden tilan.
• Se rakentaa täysin uuden puun alusta alkaen uuden elementtityypin perusteella.

Tarkastellaan esimerkiksi tätä muutosta:

Ennen: <div><Counter /></div>
Jälkeen: <span><Counter /></span>

Vaikka lapsikomponentti `Counter` on sama, React näkee, että juuri on muuttunut `div`-elementistä `span`-elementiksi. Se poistaa kokonaan vanhan `div`-elementin ja sen sisällä olevan `Counter`-instanssin (menettäen sen tilan) ja liittää (mount) sitten uuden `span`-elementin ja aivan uuden `Counter`-instanssin.

Tärkeä huomio: Vältä komponentin alipuun juurielementin tyypin muuttamista, jos haluat säilyttää sen tilan tai välttää kyseisen alipuun täydellisen uudelleenrenderöinnin.

Heuristiikka 2: Kehittäjät voivat vihjata pysyvistä elementeistä `key`-propsilla

Tämä on väitetysti tärkein heuristiikka, jonka kehittäjien on ymmärrettävä ja sovellettava oikein. Kun React vertaa lapsielementtien listaa, sen oletuskäyttäytyminen on iteroida molemmat listat läpi samanaikaisesti ja luoda muutos aina, kun ero löytyy.

Indeksipohjaisen vertailun ongelma

Kuvitellaan, että meillä on lista kohteita ja lisäämme uuden kohteen listan alkuun käyttämättä avaimia (keys).

Alkuperäinen lista:

• Kohde B
• Kohde C

Päivitetty lista (lisää 'Kohde A' alkuun):

• Kohde A
• Kohde B
• Kohde C

Ilman avaimia React suorittaa yksinkertaisen, indeksipohjaisen vertailun:

1. Se vertaa vanhaa kohdetta indeksissä 0 ('Kohde B') uuteen kohteeseen indeksissä 0 ('Kohde A'). Ne ovat erilaiset, joten se muuttaa ensimmäistä kohdetta.
2. Se vertaa vanhaa kohdetta indeksissä 1 ('Kohde C') uuteen kohteeseen indeksissä 1 ('Kohde B'). Ne ovat erilaiset, joten se muuttaa toista kohdetta.
3. Se näkee, että indeksissä 2 on uusi kohde ('Kohde C') ja lisää sen.

Tämä on erittäin tehotonta. React on tehnyt kaksi tarpeetonta muutosta ja yhden lisäyksen, kun ainoa tarvittava toimenpide oli yksi lisäys alkuun. Jos nämä listakohteet olisivat monimutkaisia komponentteja omalla tilallaan, tämä voisi johtaa vakaviin suorituskykyongelmiin ja bugeihin, koska tila voisi sekoittua komponenttien välillä.

`key`-propsin voima

The `key`-propsi tarjoaa ratkaisun. Se on erityinen merkkijonoattribuutti, joka sinun on sisällytettävä luodessasi elementtilistoja. Avaimet antavat Reactille vakaan identiteetin jokaiselle elementille.

Palataan samaan esimerkkiin, mutta tällä kertaa vakailla, uniikeilla avaimilla:

Alkuperäinen lista:

• Kohde B
• Kohde C

Päivitetty lista:

• Kohde A
• Kohde B
• Kohde C

Nyt Reactin vertailuprosessi on paljon älykkäämpi:

1. React tarkastelee uuden listan lapsia ja löytää elementit avaimilla 'b' ja 'c'.
2. Se tietää, että elementit avaimilla 'b' ja 'c' ovat jo olemassa vanhassa listassa, joten se vain siirtää ne.
3. Se näkee, että on olemassa uusi elementti avaimella 'a', jota ei ollut aiemmin, joten se luo ja lisää sen.

Tämä on paljon tehokkaampaa. React tunnistaa oikein, että sen tarvitsee tehdä vain yksi lisäys. Komponentit, jotka liittyvät avaimiin 'b' ja 'c', säilytetään, ja ne ylläpitävät sisäisen tilansa.

Kriittinen sääntö avaimille: Avainten on oltava vakaita, ennustettavia ja uniikkeja sisarustensa kesken. Taulukon indeksin käyttäminen avaimena (`items.map((item, index) =>

...

)`) on anti-pattern, jos listaa voidaan koskaan järjestellä uudelleen, suodattaa tai siitä voidaan lisätä/poistaa kohteita keskeltä, koska se johtaa samoihin ongelmiin kuin ilman avainta oleminen. Parhaat avaimet ovat datasi uniikkeja tunnisteita, kuten tietokannan ID.

Evoluutio: Stack-arkkitehtuurista Fiber-arkkitehtuuriin

Yllä kuvattu sovitusalgoritmi oli Reactin perusta monien vuosien ajan. Sillä oli kuitenkin yksi suuri rajoitus: se oli synkroninen ja estävä. Tätä alkuperäistä toteutusta kutsutaan nykyään nimellä Stack Reconciler.

Vanha tapa: The Stack Reconciler

Stack Reconcilerissa, kun tilan päivitys laukaisi uudelleenrenderöinnin, React kävi rekursiivisesti läpi koko komponenttipuun, laski muutokset ja sovelsi ne DOMiin – kaikki yhtenä, keskeytymättömänä sekvenssinä. Pienille päivityksille tämä oli hyvä. Mutta suurille komponenttipuille tämä prosessi saattoi kestää merkittävän ajan (esim. yli 16 ms), estäen selaimen pääsäikeen toiminnan. Tämä aiheutti käyttöliittymän reagoimattomuutta, johtaen pudotettuihin frameihin, nykiviin animaatioihin ja huonoon käyttäjäkokemukseen.

Esittelyssä React Fiber (React 16+)

Ratkaistakseen tämän ongelman Reactin tiimi aloitti monivuotisen projektin kirjoittaakseen ydinsovitusalgoritmin kokonaan uudelleen. Tulos, joka julkaistiin React 16:ssa, on nimeltään React Fiber.

Fiber-arkkitehtuuri suunniteltiin alusta alkaen mahdollistamaan rinnakkaisuus (concurrency) – kyky Reactille työskennellä useiden tehtävien parissa kerralla ja vaihtaa niiden välillä prioriteetin mukaan.

"Fiber" on tavallinen JavaScript-olio, joka edustaa työ_yksikköä. Se sisältää tietoa komponentista, sen syötteistä (propsit) ja tulosteista (lapset). Rekursiivisen läpikäynnin sijaan, jota ei voitu keskeyttää, React käsittelee nyt linkitettyä listaa fiber-solmuista, yksi kerrallaan.

Tämä uusi arkkitehtuuri avasi useita keskeisiä kyvykkyyksiä:

• Inkrementaalinen renderöinti: Se voi jakaa renderöintityön pieniin paloihin ja levittää sen useille frameille.
• Priorisointi: Se voi antaa eri prioriteettitasoja erilaisille päivitystyypeille. Esimerkiksi käyttäjän kirjoittaminen syöttökenttään on korkeamman prioriteetin tehtävä kuin taustalla haettava data.
• Pysäytettävyys ja peruutettavuus: Se voi keskeyttää matalan prioriteetin päivityksen työn käsitelläkseen korkean prioriteetin päivityksen ja voi jopa peruuttaa tai käyttää uudelleen työtä, jota ei enää tarvita.

Fiberin kaksi vaihetta

Fiberin alla renderöintiprosessi on jaettu kahteen erilliseen vaiheeseen:

1. Renderöinti/sovitus-vaihe (Asynkroninen): Tässä vaiheessa React käsittelee fiber-solmuja rakentaakseen "work-in-progress"-puun. Se kutsuu komponenttien `render`-metodeja ja ajaa vertailualgoritmin määrittääkseen, mitä muutoksia DOMiin on tehtävä. Ratkaisevaa on, että tämä vaihe on keskeytettävissä. React voi pysäyttää tämän työn käsitelläkseen jotain tärkeämpää ja jatkaa sitä myöhemmin. Koska se voidaan keskeyttää, React ei sovella mitään todellisia DOM-muutoksia tässä vaiheessa välttääkseen epäjohdonmukaisen käyttöliittymän tilan.
2. Commit-vaihe (Synkroninen): Kun work-in-progress-puu on valmis, React siirtyy commit-vaiheeseen. Se ottaa lasketut muutokset ja soveltaa ne todelliseen DOMiin. Tämä vaihe on synkroninen eikä sitä voi keskeyttää. Tämä varmistaa, että käyttäjä näkee aina johdonmukaisen käyttöliittymän. Elinkaarimetodit, kuten `componentDidMount` ja `componentDidUpdate`, sekä `useLayoutEffect`- ja `useEffect`-hookit suoritetaan tässä vaiheessa.

Fiber-arkkitehtuuri on perusta monille Reactin moderneille ominaisuuksille, kuten `Suspense`, rinnakkainen renderöinti, `useTransition` ja `useDeferredValue`, jotka kaikki auttavat kehittäjiä rakentamaan reagoivampia ja sulavampia käyttöliittymiä.

Käytännön optimointistrategioita kehittäjille

Reactin sovitusprosessin ymmärtäminen antaa sinulle voiman kirjoittaa suorituskykyisempää koodia. Tässä on joitakin käytännön strategioita:

1. Käytä aina vakaita ja uniikkeja avaimia listoille

Tätä ei voi korostaa liikaa. Se on yksittäinen tärkein optimointi listoille. Käytä uniikkia ID:tä datastasi (esim. `product.id`). Vältä taulukon indeksien käyttöä, ellei lista ole täysin staattinen eikä koskaan muutu.

2. Vältä turhia uudelleenrenderöintejä

Komponentti renderöidään uudelleen, jos sen tila muuttuu tai sen vanhempi renderöidään uudelleen. Joskus komponentti renderöidään uudelleen, vaikka sen tuotos olisi identtinen. Voit estää tämän käyttämällä:

• `React.memo()`: Higher-order-komponentti funktiokomponenteille. Se suorittaa komponentin propsien pinnallisen vertailun. Jos propsit eivät ole muuttuneet, React ohittaa komponentin uudelleenrenderöinnin ja käyttää uudelleen viimeksi renderöityä tulosta.
• `useCallback()`: Komponentin sisällä määritellyt funktiot luodaan uudelleen joka renderöinnillä. Jos välität näitä funktioita propseina `React.memo`-kääreessä olevalle lapsikomponentille, lapsi renderöityy uudelleen, koska funktioksioprops on teknisesti uusi funktio joka kerta. `useCallback` memoizoi funktion itsensä varmistaen, että se luodaan uudelleen vain, jos sen riippuvuudet muuttuvat.
• `useMemo()`: Samanlainen kuin `useCallback`, mutta arvoille. Se memoizoi kalliin laskennan tuloksen. Laskenta suoritetaan uudelleen vain, jos jokin sen riippuvuuksista on muuttunut. Tämä on hyödyllistä estämään kalliita laskutoimituksia joka renderöinnillä ja ylläpitämään vakaita olio/taulukko-viittauksia, jotka välitetään propseina.

3. Älykäs komponenttien koostaminen

Tapa, jolla rakennat komponenttisi, voi vaikuttaa merkittävästi suorituskykyyn. Jos osa komponenttisi tilasta päivittyy usein, yritä eristää se osista, jotka eivät päivity.

Esimerkiksi sen sijaan, että sinulla olisi yksi suuri komponentti, jossa usein muuttuva syöttökenttä aiheuttaa koko komponentin uudelleenrenderöinnin, nosta kyseinen tila omaan pienempään komponenttiinsa. Tällä tavoin vain pieni komponentti renderöityy uudelleen, kun käyttäjä kirjoittaa.

4. Virtualisoi pitkät listat

Jos sinun täytyy renderöidä listoja, joissa on satoja tai tuhansia kohteita, jopa oikeilla avaimilla, niiden kaikkien renderöinti kerralla voi olla hidasta ja kuluttaa paljon muistia. Ratkaisu on virtualisointi tai ikkunointi (windowing). Tämä tekniikka tarkoittaa, että renderöidään vain pieni osajoukko kohteita, jotka ovat tällä hetkellä näkyvissä näkymäikkunassa. Kun käyttäjä vierittää, vanhat kohteet poistetaan (unmount) ja uudet liitetään (mount). Kirjastot kuten `react-window` ja `react-virtualized` tarjoavat tehokkaita ja helppokäyttöisiä komponentteja tämän mallin toteuttamiseen.

Yhteenveto

Reactin suorituskyky ei ole sattumaa; se on seurausta harkitusta ja kehittyneestä arkkitehtuurista, joka keskittyy virtuaaliseen DOMiin ja tehokkaaseen sovitusalgoritmiin. Abstrahoimalla suoran DOM-manipulaation pois React voi ryhmitellä ja optimoida päivityksiä tavalla, jonka manuaalinen hallinta olisi uskomattoman monimutkaista.

Kehittäjinä olemme tärkeä osa tätä prosessia. Ymmärtämällä vertailualgoritmin heuristiikat – käyttämällä avaimia oikein, memoizoimalla komponentteja ja arvoja sekä rakentamalla sovelluksemme harkitusti – voimme työskennellä Reactin sovitusalgoritmin kanssa, emme sitä vastaan. Evoluutio Fiber-arkkitehtuuriin on edelleen työntänyt mahdollisuuksien rajoja, mahdollistaen uuden sukupolven sulavia ja reagoivia käyttöliittymiä.

Seuraavan kerran kun näet käyttöliittymäsi päivittyvän välittömästi tilan muutoksen jälkeen, pysähdy hetkeksi arvostamaan virtuaalisen DOMin, vertailualgoritmin ja commit-vaiheen eleganttia tanssia, joka tapahtuu konepellin alla. Tämä ymmärrys on avain nopeampien, tehokkaampien ja vankempien React-sovellusten rakentamiseen maailmanlaajuiselle yleisölle.